Editor Test Patch E3 contains fixes and improvements:
Modeller cutout screen:
FIX: Number of materials and material index were wrong for subobjects
- helps when optimising a model for frame rate by texture sharing
Engine editor:
Increased maximum value of "Turbo MOI Multiplier" to 2.0
- allows turbo to spool up slower (more turbo lag)
Rim guide in rim editor and spoke editor:
Decreased the minimum width of car rim flange (was 12mm, now 11mm)
- this is correct for the 'J' rim profile used on modern road cars
https://www.lfs.net/forum/thread/106792
Modeller cutout screen:
FIX: Number of materials and material index were wrong for subobjects
- helps when optimising a model for frame rate by texture sharing
Engine editor:
Increased maximum value of "Turbo MOI Multiplier" to 2.0
- allows turbo to spool up slower (more turbo lag)
Rim guide in rim editor and spoke editor:
Decreased the minimum width of car rim flange (was 12mm, now 11mm)
- this is correct for the 'J' rim profile used on modern road cars
https://www.lfs.net/forum/thread/106792
Last edited by Scawen, .
It's a very nice looking mod but I have been wondering what causes the slowdowns when watching on Simbroadcasts. My investigations are not complete. I'm stopping for the day but have some observations. It's not all about the number of triangles.
Incorrect setting "Concealed driver" - this should be YES - absolutely this vehicle has a concealed driver (it's not a motorbike or a kart). This one setting appears to waste around 3% of CPU with 32 on the grid.
By the way, "Wheel visibility" should be "inside covered" though I think this is only for looks now. It's not an open wheel racing car, so this will produce a better lighting effect on the wheels.
Another graphical cost is lack of texture sharing. For example the wheel objects are slower to draw than they could be because the alpha cutouts use 3 different textures. The 3 different transparent textures should share a single texture page, so LFS does not have to waste CPU time instructing D3D to switch between textures (texture switching is slow). If you set this right, then when drawing wheel alpha, instead of 3 texture switches and 3 draw calls, it would do a single texture switch and a single draw call.
There could be similar case in the main object (or other subobjects) but I haven't looked much. I do see an S and a backwards S using the same texture but flipped. Can't you use the same texture but flip the cutout?
Of course "repeating textures" cannot share a texture page. But some other textures can, and this can avoid switching between textures during the render of the car, saving CPU time.
EDIT: (next morning)
You can easily get the spoke object down to one single texture instead of 5 at the moment. How to do that:
1) Combine the 4 256 textures onto a single 512 page, the obvious way.
2) For the "unnamed" (no texture) cutout use a small white square on the new texture page. There is space beside the bolts.
More optimisations:
- If possible, combine the hub object into the spoke object. Every moving subobject is a frame rate hit.
- Change "muffler" subobject into an attachment. "Attachment" subobjects are merged into the main object so they don't cause the same frame rate hits as a moving subobject. The vibrating muffler gimmick isn't worth the frame rate hit.
- Steering wheel subobject can be made way more efficient by combining textures. The 11 small button textures could be combined onto a single texture. The [no texture] page can be eliminated by using a small square from the new texture. And the "plain transparent" texture at the end of the list can also be combined into the same texture page. So this combines 13 textures into a single texture page. Only the two repeating textures need to be left on their own page. 15 textures on the steering wheel now, can be reduced to only 3.
Let's do some maths, for 40 cars on the grid.
For the wheel objects described above, we save 4 texture changes per wheel = 16 per car = 640 per graphical frame.
For the steering wheel optimisation, we save 12 texture changes per car = 480 per graphical frame.
So by these simple changes we save 1120 calls to "Set texture" every graphical frame.
Also don't use "TEA" (Tree Edge Alpha). Tree Edge Alpha is not supported for vehicles, it's a special thing for trees with intersecting polygons that only works for world objects. Applied to a car it looks exactly the same as ALPHA so you are adding one more material for no reason.
[I notice one bug, in cutout mode when a subobject is selected: "materials : X" at the top is showing the number for the main object. I'll fix this in next editor test patch. You really should be aiming to reduce the number of materials so that number would help.]
Incorrect setting "Concealed driver" - this should be YES - absolutely this vehicle has a concealed driver (it's not a motorbike or a kart). This one setting appears to waste around 3% of CPU with 32 on the grid.
By the way, "Wheel visibility" should be "inside covered" though I think this is only for looks now. It's not an open wheel racing car, so this will produce a better lighting effect on the wheels.
Another graphical cost is lack of texture sharing. For example the wheel objects are slower to draw than they could be because the alpha cutouts use 3 different textures. The 3 different transparent textures should share a single texture page, so LFS does not have to waste CPU time instructing D3D to switch between textures (texture switching is slow). If you set this right, then when drawing wheel alpha, instead of 3 texture switches and 3 draw calls, it would do a single texture switch and a single draw call.
There could be similar case in the main object (or other subobjects) but I haven't looked much. I do see an S and a backwards S using the same texture but flipped. Can't you use the same texture but flip the cutout?
Of course "repeating textures" cannot share a texture page. But some other textures can, and this can avoid switching between textures during the render of the car, saving CPU time.
EDIT: (next morning)
You can easily get the spoke object down to one single texture instead of 5 at the moment. How to do that:
1) Combine the 4 256 textures onto a single 512 page, the obvious way.
2) For the "unnamed" (no texture) cutout use a small white square on the new texture page. There is space beside the bolts.
More optimisations:
- If possible, combine the hub object into the spoke object. Every moving subobject is a frame rate hit.
- Change "muffler" subobject into an attachment. "Attachment" subobjects are merged into the main object so they don't cause the same frame rate hits as a moving subobject. The vibrating muffler gimmick isn't worth the frame rate hit.
- Steering wheel subobject can be made way more efficient by combining textures. The 11 small button textures could be combined onto a single texture. The [no texture] page can be eliminated by using a small square from the new texture. And the "plain transparent" texture at the end of the list can also be combined into the same texture page. So this combines 13 textures into a single texture page. Only the two repeating textures need to be left on their own page. 15 textures on the steering wheel now, can be reduced to only 3.
Let's do some maths, for 40 cars on the grid.
For the wheel objects described above, we save 4 texture changes per wheel = 16 per car = 640 per graphical frame.
For the steering wheel optimisation, we save 12 texture changes per car = 480 per graphical frame.
So by these simple changes we save 1120 calls to "Set texture" every graphical frame.
Also don't use "TEA" (Tree Edge Alpha). Tree Edge Alpha is not supported for vehicles, it's a special thing for trees with intersecting polygons that only works for world objects. Applied to a car it looks exactly the same as ALPHA so you are adding one more material for no reason.
[I notice one bug, in cutout mode when a subobject is selected: "materials : X" at the top is showing the number for the main object. I'll fix this in next editor test patch. You really should be aiming to reduce the number of materials so that number would help.]
Last edited by Scawen, .
Some thoughts...
First 2 paragraphs are just "history of last few days" you can ignore and go to "Summary of some issues" below.
1) Although I didn't want to get involved with mods again this month, I ended up falling into it when we discovered the exploits some people were using. I'm not talking about moderate amounts, but some ugly abuses of the system. In conjunction with reports of pit-out glitches, it was important to act. We need some sense in the mods. I became aware of some terrible low quality mods, for example: (a) massively high polygon model, with stripped out main config to pass the export check (b) wheels with over 10,000 triangles. So we had to do something and the obvious starting point was to enforce the limits that have always been there and are allowed in the current editor.
2) Discussion, participation and cooperation on this thread has done at least two positive things (a) increased awareness of the Rim Editor that has improved a lot since the older version and (b) increased my understanding of some of the limitations of the Spoke Editor / Rim Editor combination (especially when using the proper limits).
Summary of some issues and possible solutions, future and present:
1) The Rim Editor suffers from lack of material selection. This isn't a problem for most rim designs but there are still a lot of rim designs for which this is a serious limitation. Rims use the first mapping in the Spoke Editor, for their texture and material settings. A mapping selector could be added in an incompatible version at some point, but that is not desirable at this time.
2) In cases where Rim Editor does not provide enough flexibility, Spoke Editor's limitation of 1600 triangles can be a problem. Rim editor actually allows 22 surfaces * 60 around * 2 triangles per quad = 2640 triangles. Today I have been thinking that the triangle budget could be shared between rim and spoke object, a total of 2640 + 1600 = 4240 triangles per wheel.
3) This budget sharing suggestion allows an empty rim object and up to 4240 in the spoke object if that is the way you prefer to do it but this has a limitation that the "steel rim guide" (yellow in rim editor) cannot be seen in the spoke editor. This is a problem in my opinion because in the real world, wheels of a certain specification must have a rim flange in the right place and the right size. This is necessary so that different manufacturers' tyres can be mounted on different manufacturers' wheels. The shape of the rim flange (on the inside, where it meets the tyre) is specified by standards organisations such as ETRTO. Road cars use a "J Rim Profile" in case you want to read about it (though information is scarce). This is not easy to enforce properly in a freehand editor. I've been wondering about a 3 dimensional version of the rim guide that is currently visible in the spoke editor, for the spoke editor, showing in a bright colour the minimum amount of material that you should cover to produce a realistic rim for the given wheel dimensions.
4) Additionally the editor needs to check limits properly before export to avoid confusion when uploading. I don't see it as a big deal to release an editor test patch if the output is fully compatible with the public version of LFS.
First 2 paragraphs are just "history of last few days" you can ignore and go to "Summary of some issues" below.
1) Although I didn't want to get involved with mods again this month, I ended up falling into it when we discovered the exploits some people were using. I'm not talking about moderate amounts, but some ugly abuses of the system. In conjunction with reports of pit-out glitches, it was important to act. We need some sense in the mods. I became aware of some terrible low quality mods, for example: (a) massively high polygon model, with stripped out main config to pass the export check (b) wheels with over 10,000 triangles. So we had to do something and the obvious starting point was to enforce the limits that have always been there and are allowed in the current editor.
2) Discussion, participation and cooperation on this thread has done at least two positive things (a) increased awareness of the Rim Editor that has improved a lot since the older version and (b) increased my understanding of some of the limitations of the Spoke Editor / Rim Editor combination (especially when using the proper limits).
Summary of some issues and possible solutions, future and present:
1) The Rim Editor suffers from lack of material selection. This isn't a problem for most rim designs but there are still a lot of rim designs for which this is a serious limitation. Rims use the first mapping in the Spoke Editor, for their texture and material settings. A mapping selector could be added in an incompatible version at some point, but that is not desirable at this time.
2) In cases where Rim Editor does not provide enough flexibility, Spoke Editor's limitation of 1600 triangles can be a problem. Rim editor actually allows 22 surfaces * 60 around * 2 triangles per quad = 2640 triangles. Today I have been thinking that the triangle budget could be shared between rim and spoke object, a total of 2640 + 1600 = 4240 triangles per wheel.
3) This budget sharing suggestion allows an empty rim object and up to 4240 in the spoke object if that is the way you prefer to do it but this has a limitation that the "steel rim guide" (yellow in rim editor) cannot be seen in the spoke editor. This is a problem in my opinion because in the real world, wheels of a certain specification must have a rim flange in the right place and the right size. This is necessary so that different manufacturers' tyres can be mounted on different manufacturers' wheels. The shape of the rim flange (on the inside, where it meets the tyre) is specified by standards organisations such as ETRTO. Road cars use a "J Rim Profile" in case you want to read about it (though information is scarce). This is not easy to enforce properly in a freehand editor. I've been wondering about a 3 dimensional version of the rim guide that is currently visible in the spoke editor, for the spoke editor, showing in a bright colour the minimum amount of material that you should cover to produce a realistic rim for the given wheel dimensions.
4) Additionally the editor needs to check limits properly before export to avoid confusion when uploading. I don't see it as a big deal to release an editor test patch if the output is fully compatible with the public version of LFS.
Last edited by Scawen, .
Here is the link to the test patch thread which shows changes in test patches after test patch D48.
https://www.lfs.net/forum/thread/106005-Test-Patch-D64
I can't see any relevant changes in AI there, so I believe their driving did not change since D48.
https://www.lfs.net/forum/thread/106005-Test-Patch-D64
I can't see any relevant changes in AI there, so I believe their driving did not change since D48.
It's not the time to talk to me about changing the limits. I am working on other things and could do without a battle against mod hackers.
The rim editor updates were introduced during the test patch stages. It would have been good to discuss it at that time, as you may know that is what test patches are for. To introduce updates and test them. The idea of a test patch is not just to keep quiet and hope I don't notice the use of hacking tools, which I admit I have been slow to notice.
There is a rim editor, a spoke editor and there are also hub objects, that you are free to use within the limits.
The rim editor updates were introduced during the test patch stages. It would have been good to discuss it at that time, as you may know that is what test patches are for. To introduce updates and test them. The idea of a test patch is not just to keep quiet and hope I don't notice the use of hacking tools, which I admit I have been slow to notice.
There is a rim editor, a spoke editor and there are also hub objects, that you are free to use within the limits.
Rim Editor
EDIT: This thread is now obsolete.
A new triangle budget of 4240 is shared between spoke and rim objects
You can get the new editor in the Editor Test Patch Thread
I recently learned that some people discovered a hack that allowed them to exceed the triangle limits for spoke objects.
The mod checker now makes sure you do not exceed triangle limits when uploading a mod.
There shouldn't be any need to exceed the limit of 1600 triangles per spoke object.
The trick is... do not include the rim in the spoke object!
Use the RIM EDITOR to make the rim.
Use the SPOKE EDITOR to make the spokes.
The rim editor has been updated in the recent update. I did a lot of work on it and it is a lot better than in the original LFS Editor. You create the cross-section of a rim by adding points and connecting the points with surfaces. The rim uses the first mapping from the spoke object, so you can use any material settings you wish (including a texture if you like).
There is a new guide in the rim editor that shows the cross-section of a steel rim when you are in the rim editor. The idea is that the steel rim represents the minimum amount of material. Alloys have thicker metal and exceed the steel rim outline.
These two images show the sequence for setting up a realistic rim.
EDIT: Added 3 more images showing examples of steel rim and two (of many) possibilities for alloy rims.
First set the correct rim width.
Then edit the rim, making sure you cover the steel rim profile.
An example of a steel rim style:
Alloy example 1:
Alloy example 2:
A new triangle budget of 4240 is shared between spoke and rim objects
You can get the new editor in the Editor Test Patch Thread
I recently learned that some people discovered a hack that allowed them to exceed the triangle limits for spoke objects.
The mod checker now makes sure you do not exceed triangle limits when uploading a mod.
There shouldn't be any need to exceed the limit of 1600 triangles per spoke object.
The trick is... do not include the rim in the spoke object!
Use the RIM EDITOR to make the rim.
Use the SPOKE EDITOR to make the spokes.
The rim editor has been updated in the recent update. I did a lot of work on it and it is a lot better than in the original LFS Editor. You create the cross-section of a rim by adding points and connecting the points with surfaces. The rim uses the first mapping from the spoke object, so you can use any material settings you wish (including a texture if you like).
There is a new guide in the rim editor that shows the cross-section of a steel rim when you are in the rim editor. The idea is that the steel rim represents the minimum amount of material. Alloys have thicker metal and exceed the steel rim outline.
These two images show the sequence for setting up a realistic rim.
EDIT: Added 3 more images showing examples of steel rim and two (of many) possibilities for alloy rims.
First set the correct rim width.
Then edit the rim, making sure you cover the steel rim profile.
An example of a steel rim style:
Alloy example 1:
Alloy example 2:
Last edited by Scawen, .
I confirm automatic downshifts occur at lower RPM and this was done during the test patch stage, with plenty of time for testing. The main reason it was done was because of the automatic shift at high rpm unsettling bikes a lot.
I am sure the new downshift time will not be ideal for all vehicles on all corners, but then it never was really ideal.
Competitive racers use a gear shifter to choose the best shift time so that is really the way forward and I believe you'll find it more fun in the end.
I am sure the new downshift time will not be ideal for all vehicles on all corners, but then it never was really ideal.
Competitive racers use a gear shifter to choose the best shift time so that is really the way forward and I believe you'll find it more fun in the end.
Thank you for that test.
Yeah, I wasn't able to do that, as it was a bit complicated as the car doesn't really have its engine on. It wasn't straightforward like the others.
D63 (LFS and Editor versions) out now and I hope to do no more test patches at all.
If you can test, please do. I really don't want bug reports immediately after 0.7E is released.
LFS: https://lfs.net/forum/thread/106005
Editor: https://lfs.net/forum/thread/106004
If you can test, please do. I really don't want bug reports immediately after 0.7E is released.
LFS: https://lfs.net/forum/thread/106005
Editor: https://lfs.net/forum/thread/106004
This is now done in D63. Please test if you can.
In D63:
New switch options for rotator and slider: signal / light switch
New flip function "with driver" (move across with driver / no flip)
There is no separate switch for sidelights, but the light switch option goes:
0 - off
1 - sidelights (1 x rotation)
2 - headlights (2 x rotation)
The signal switch goes:
left: -1 x rotation
off: 0
right: 1 x rotation
It's last day coding which is not recommended, but will be OK if you can test it.
What if the test patch is installed immediately after the original install, without ever running LFS? Can you unlock, download mods and skins?
Could Windows be doing some kind of virus prevention? I don't think anything has actually changed in the code relating to this, since 0.7D. So I wonder if it's more about the way it is being installed.
Could Windows be doing some kind of virus prevention? I don't think anything has actually changed in the code relating to this, since 0.7D. So I wonder if it's more about the way it is being installed.
Options - Display - Extra status info
Thanks, I've updated it in the system.
Thanks for the test.
I've added some unlocks, in case you could test again.
Anyone who wants to run that test, please go ahead. I can give you more unlocks if you are running out. We also reset all unlocks when a new patch is released, so you don't lose anything.
[ EDIT: It seems all figured out now, see below ]
Last edited by Scawen, .
Thank you for the test, it's good to fix that one! 
I am a bit too mindblown at the moment, to run the test myself. I have to go to bed. But would appreciate anyone else trying that.
As I understand you:
- fresh install of 0.7D, do not save mods
- install D62 immediately and unlock
- go online to server with mods
- if your bug is reproduced then it fails to save mods
[ EDIT: It seems all figured out now, see below ]
As I understand you:
- fresh install of 0.7D, do not save mods
- install D62 immediately and unlock
- go online to server with mods
- if your bug is reproduced then it fails to save mods
[ EDIT: It seems all figured out now, see below ]
Last edited by Scawen, .
Thanks for the test, I've added some more unlocks to your account.
Development is now finished for 0.7E!
Report IMPORTANT BUGS ONLY please!
(I have updated the spinner ending rotation and plan to release that in a test patch tomorrow)
Last edited by Scawen, .
Thank you for the test!
I see what you mean. My fix was only when ENTER key is pressed, but I can instead do the fix when any key is pressed.
It should work now, in D62. Please let me know!
https://www.lfs.net/forum/thread/106005
I see what you mean. My fix was only when ENTER key is pressed, but I can instead do the fix when any key is pressed.
It should work now, in D62. Please let me know!
https://www.lfs.net/forum/thread/106005
The fix is in Test Patch D61.
Please let me know if it works!
https://www.lfs.net/forum/thread/106005
Please let me know if it works!
https://www.lfs.net/forum/thread/106005
Well, that would take a few weeks, and the release is this weekend, so no.
That is something to do when I only have to work on one version of LFS,
By the way, can you tell me where I asked for random off topic requests on the test patch thread? I thought it was pretty clear what a test patch thread is about. Some people seem to have great difficulty understanding.
That is something to do when I only have to work on one version of LFS,
By the way, can you tell me where I asked for random off topic requests on the test patch thread? I thought it was pretty clear what a test patch thread is about. Some people seem to have great difficulty understanding.
[duplicate of post in LFS test patch thread]
Now, in the last day of coding, I am doing a few safe remaining things.
Normally I request for people to avoid spamming me with the same reports they already made before.
That still applies, but in the case of actual bugs or anything that we would regret not fixing before this weekend's release, please do tell me if I seem to have missed or forgotten anything.
Now, in the last day of coding, I am doing a few safe remaining things.
Normally I request for people to avoid spamming me with the same reports they already made before.
That still applies, but in the case of actual bugs or anything that we would regret not fixing before this weekend's release, please do tell me if I seem to have missed or forgotten anything.
Test Patch D60
Graphics:
Support for stretched tyres (when rim is wider than ideal)
Commands:
/key command accepts 12 keys described by a word (see Commands.txt)
Misc:
Updated document Commands.txt (in docs folder)
Download: https://www.lfs.net/forum/thread/106005
Graphics:
Support for stretched tyres (when rim is wider than ideal)
Commands:
/key command accepts 12 keys described by a word (see Commands.txt)
Misc:
Updated document Commands.txt (in docs folder)
Download: https://www.lfs.net/forum/thread/106005
It's not the right place, as that is a suggestion unrelated to this test patch. That sounds like a mod suggestion and there is a dedicated forum section for that.
Release this weekend - call for testing
Dear Racers,
We plan to release a new official version this weekend, probably on Sunday.
There's a lot in it, including many improvements for mods. In the new year I will be focussing on the new graphics and physics version, but that is not what this patch is about.
Please test the LFS version now if you can.
LFS Test Patch: https://www.lfs.net/forum/thread/106005
If you are a mod creator, please test the new editor patch.
LFS Editor Test Patch: https://www.lfs.net/forum/thread/106004
You'll see the list of changes is really long. Have a look through the changes if you can!
Or just get the patch and do what you normally do, let us know if there are any problems.
Thanks!
We plan to release a new official version this weekend, probably on Sunday.
There's a lot in it, including many improvements for mods. In the new year I will be focussing on the new graphics and physics version, but that is not what this patch is about.
Please test the LFS version now if you can.
LFS Test Patch: https://www.lfs.net/forum/thread/106005
If you are a mod creator, please test the new editor patch.
LFS Editor Test Patch: https://www.lfs.net/forum/thread/106004
You'll see the list of changes is really long. Have a look through the changes if you can!
Or just get the patch and do what you normally do, let us know if there are any problems.
Thanks!
Test Patch D59
Graphics:
Small indicators on side of XRG/XRT/FXO/LX4/LX6/RAC/FZ5 now flash
Subobject indicators left / right now relative to whole vehicle
FIX: Lighting of subobjects and wheels was as if at vehicle centre
https://www.lfs.net/forum/thread/106005
Graphics:
Small indicators on side of XRG/XRT/FXO/LX4/LX6/RAC/FZ5 now flash
Subobject indicators left / right now relative to whole vehicle
FIX: Lighting of subobjects and wheels was as if at vehicle centre
https://www.lfs.net/forum/thread/106005
Test Patch D58
Lights:
Headlight switch now incompatible between versions < D50 and >= D50
FIX: Extra light of remote cars was not visible when switched on
Moving subobjects:
Popup headlight system generalised for moving objects with switches
Light / horn switches work even if car does not have that feature
Download: https://www.lfs.net/forum/thread/106005
Lights:
Headlight switch now incompatible between versions < D50 and >= D50
FIX: Extra light of remote cars was not visible when switched on
Moving subobjects:
Popup headlight system generalised for moving objects with switches
Light / horn switches work even if car does not have that feature
Download: https://www.lfs.net/forum/thread/106005
FGED GREDG RDFGDR GSFDG